When designing increasingly complex processors or IC chips such as Application-Specific ICs (ASICs) and system-on-chips (SoC's), functional verification has proven to be a major bottleneck in achieving time-to-market goals. Many companies now realize that functional verification of complex chips has become an inefficient, unwieldy, and incomplete process. Design teams report that functional verification of medium- to large-complexity processors, ASICs or SOC's may consume over 70% of the project's manpower, schedule and budget. In spite of the time and resources consumed by functional verification, it is still often incomplete, allowing design bugs to go undetected. Improved functional verification can cut costs, improve design quality and accelerate time-to-market, as well as allowing companies to sharply increase the productivity of precious verification personnel.
The design process for a chip starts with the creation of a functional specification for the design. Once the functional specification has been completed, the verification team typically creates a test plan that specifies the design features and functions to be tested at both the block and system levels. The verification team then creates tests such as deterministic tests and weighted-random tests to verify design functionality until all test plan requirements have been met. The verification process involves developing and simulating tests that are used to determine whether design components (e.g., processor units, I/O busses, resources, functions, etc.) behave according to their functional specification in a process known as functional verification. Functional verification is often an iterative process where the entire system (or at least all its major features) is tested on a continuous basis for the duration of the design process. Functional verification is typically completed before fabrication, as finding and fixing errors, or bugs, after fabrication proves to be time-consuming and expensive. Functional coverage is the study and analysis of the quality and completeness of functional verification. It includes statistical, stochastic and heuristic analysis of functional verification progress and completeness.
Software tools have been developed to help designers and testers with the functional verification process. A design under test (DUT) may be described using a hardware description language (HDL) such as VHSIC (Very High Speed Integrated Circuits) HDL (VHDL) or Verilog. Automation tools such as Verisity Design, Inc.'s (Verisity) (owned by Cadence Design Systems, Inc.) Specman® testbench automation software provide an environment for generation of functional tests, data and temporal checking, functional coverage analysis, and HDL simulation control.
Some design components require sophisticated modeling in order to properly simulate their performance (and thus to complete functional verification). Functional verification of a parameterizable, high-speed, self-aligning, elastic I/O design, for example, poses problems with existing verification environments. Special conditions often occur in the DUT when simulating error scenarios and distortions on certain bits of a bus which fall on the boundaries of logical or physical hierarchical layers (such as ‘bus’, ‘group’, and ‘pack’ layers) in the design. Other unique scenarios can also occur when, for example, every bit in a group or pack has been affected by self-healing, errors, or various distortions. Since these boundaries can change due to the parameterizable nature of the design, to properly verify a design with these special conditions a mechanism is needed to indicate whether the functional simulation has provided for these conditions to occur on all of the important boundaries and on entire hierarchical layers of interest. Existing verification languages, however, are limited in that they do not permit coverage items using variable ranges, restricting their use for designs with sizes and boundaries of the bus hierarchies that are parameterizable and thus not constants (such as elastic I/O designs).
One solution to this problem would be to create preprocessor “#define” constants for each bus configuration and to use those constants in the coverage items ranges. While this solution would be effective in many situations, it would be tedious, labor-intensive, and subject to error. In this solution, new configuration files would need to be generated to define the specific sizes and boundaries for each group and pack in the bus, for example, and these files would need to be separately maintained, archived, and associated with their specific VHDL configurations. This method would therefore consume extra space, create file clutter, and be difficult and time-consuming to manage. There is, therefore, a need for an improved mechanism for functional simulation and verification of parameterizable components such as I/O bus designs, particularly for verifying error scenarios or specific test patterns on logical and physical hierarchy layer boundaries or on entire hierarchical layers.